\chapter{Análise Formal baseada em Redes de Petri Coloridas}\label{cap:analise}

     Este capítulo apresenta a validação formal da arquitetura utilizando Redes
de Petri Coloridas. A validação é feita através de duas abordagens: (i)
análise funcional do SIPSpace, utilizando-se a ferramenta de análise de espaço
de estado; e (ii) análise de desempenho da rede através de simulação.


%%----------------------------------------------------------------------------
% Análise funcional
%
\section{Análise Funcional do SIPSpace}

    A análise funcional do SIPSpace está baseada na especificação da transação
SIP para a operação INVITE (\textit{SIP INVITE Transaction}), conforme apresentado
anteriormente na seção \ref{subsec:CPNSipSpace}, utilizando o modelo CPN também
apresentado na mesma seção.

%
% State Space
%
\subsection{Análise de Espaço de Estado}

   A ferramenta CPN gera um relatório de espaço de estado (\textit{state space
report}) para realizar análise de propriedades comportamentais de um modelo.
Quando o espaço de estado é calculado, pode-se utilizar funções CPN ML de
consulta para extrair resultados e efetuar análise com maior nível de detalhes.
Adicionalmente, a ferramenta gera um grafo conectado como suporte para análise de
propriedades comportamentais.

   Para validar as propriedades funcionais do SIPSpace, utilizamos a análise de
espaço de estado. As propriedades de interesse são \textit{dead markings},
\textit{dead transitions}, e \textit{live-locks}.

   Baseado nas propriedades de interesse, é importante considerar as seguintes
questões:

\begin{enumerate}
 \item A propriedade \textit{dead marking}, ou seja, a marcação final do modelo após a
simulação, deve ser os lugares \texttt{ClientTransaction} e \texttt{ServerTransaction} com
as marcações \texttt{terminated} e \texttt{terminatedS} respectivamente. Isso mostra que o
protocolo funciona de acordo com a especificação.

  \item Espera-se que o protocolo não apresente \textit{dead code}, ou seja,
nenhuma transição que nunca será habilitada. 

  \item Também não deve apresentar \textit{live-lock}, ou seja, ciclos no espaço de
estado. A ausência de \textit{live-locks} pode ser constatada quando o relatório de
espaço de estado apresentar o mesmo número de nós do grafo SCC.

\end{enumerate}

   Para analisar com mais detalhes as \textit{dead markings} geradas no relatório de
espaço de estado, utilizamos a função CPN-ML a seguir:

        \begin{algorithm}
          \begin{algorithmic}[1]
            \STATE fun desired n =
               \STATE\hspace{\algorithmicindent} 
                 ((Mark.top'ClientTransaction 1 n) == 1`terminated) andalso
               \STATE\hspace{\algorithmicindent}
                 ((Mark.top'ServerTransaction 1 n) == 1`terminatedS);
          \end{algorithmic}
        \end{algorithm}

    Após calcular o espaço de estado e o grafo conectado, as seguintes
estatísticas foram geradas.

\begin{verbatim}
  State Space            Scc Graph
     Nodes:  341            Nodes:  341
     Arcs:   441            Arcs:   441
     Secs:   0              Secs:   0
     Status: Full
\end{verbatim}

    Como pode-se observar, tanto o relatório de espaço de estado como o grafo conectado
geraram 341 nós e 441 arcos. Com esse resultado, concluímos que o SIPSpace não possui
ciclos (\textit{live-lock}). 

    Outra propriedade interessante do relatório é o \textit{Best Upper Multi-set
Bounds}, conforme mostra o relatório a seguir. Esta propriedade mostra o conjunto de
marcações alcançadas em cada lugar do modelo.

\begin{verbatim}
 top'ClientTransaction 1   top'Send_Request 1  
  1`calling++               1`INVITE++  
  1`proceeding++            1`ACK
  1`completed++             
  1`accepted++             top'Send_Response 1 
  1`terminated              1`r1xx++
                            1`r2xx++
 top'ServerTransaction 1    1`r3xx
  1`idle++ 
  1`proceedingS++          top'Tuple_Space 1
  1`completedS++            1`(INVITE,noneResp)++
  1`acceptedS++             1`(ACK,noneResp)++
  1`terminatedS             1`(noneReq,r1xx)++
                            1`(noneReq,r2xx)++
                            1`(noneReq,r3xx)
\end{verbatim} 

   Analisando os lugares principais, (\texttt{ClientTransaction},
\texttt{ServerTransaction}, \texttt{SendRequest}, \texttt{SendResponse} e \texttt{Tuple
Space}) mostrados no relatório, pode-se observar que: 

\begin{itemize}
   \item A transação cliente, representada no relatório por
\texttt{top'ClientTransaction 1}, passou por todos os estados possíveis, na ordem correta,
ou seja, recebeu todas as marcações representando os devidos estados. 

   \item A transação servidor, representada no relatório por
\texttt{top'ServerTransaction 1}, passou por todos os estados possíveis, na ordem correta,
ou seja, recebeu todas as marcações representando os devidos estados. 

   \item A transação cliente enviou todas requisições possíveis, ou seja INVITE e ACK.
Pode-se observar isso no relatório através do lugar  \texttt{top'Send\_Request 1}.

   \item A transação servidor enviou todas as respostas esperadas, ou seja, r1xx, r2xx e
r3xx. Pode-se observar isso no relatório através do lugar  \texttt{top'Send\_Response
1}.

   \item E por sua vez, o LTS, representado no relatório por \texttt{top'Tuple\_Space 1}
recebeu todas as tuplas possíveis, de requisição e resposta.
\end{itemize}

   Com base no relatório \textit{Best Upper Multi-set Bounds}, concluímos que durante a
simulação do SIPSpace todas as transições de estado, requisições e respostas possíveis
são executadas corretamente pelo SIPSpace, seguindo fielmente a especificação do
protocolo SIP.

   O relatório gerou um \textit{dead code}, i.e., \textit{dead transition} no lugar
\texttt{top'Stop\_T\_H 1}. Essa \textit{dead transition} representa o \textit{timeout} na
transação servidor quando em espera por um ACK da transação cliente. Nesse modelo, é uma
situação esperada.

   Finalmente, pode-se observar que o espaço de estado gerou 59 \textit{dead markings}.
Analisando com mais detalhes através da função de consulta \texttt{derised n} apresentada
anteriormente, observamos que 58 \textit{dead markings} estão no estado desejado, ou seja,
as transações cliente e servidor no estado \textit{terminated} e \textit{terminatedS}
respectivamente. Em uma \textit{dead marking}, a transação cliente está no estado
\textit{terminated} e a transação servidor no estado \textit{Idle}. Isso acontece em
função do disparo da transição \texttt{ClientErr}, a qual é um resultado esperado.

%
%
\subsection{Considerações}

   A análise funcional do SIPSpace através da ferramenta de cálculo de espaço
demonstrou que a mudança na forma de implementação do protocolo SIP não alterou sua
semântica, ou seja, o resultado final de um fluxo de mensagens SIP se mantém consistente
com a especificação.


%% ----------------------------------------------------------------------------
% Análise de desempenho
%% ----------------------------------------------------------------------------
\section{Análise de Desempenho da Arquitetura baseada em Espaço de Tuplas}


%
% Análise cenario
%
\subsection{Métricas e Coleta de Dados} 

  Esta sessão apresenta as métricas de desempenho consideradas para análise da arquitetura
baseada em espaço de tuplas e seu relacionamento com o modelo CPN através das funções de
monitoração e coleta de dados.


 \subsubsection{Taxa de utilização do CSCF}
 
      A taxa de utilização do CSCF, expressada por $U_{CSCF_{i}}$, indica, em termos
percentuais, a média de utilização do componente CSCF em cada Servidor IMS da rede.

      O principal objetivo dessa métrica é verificar a habilidade da arquitetura em
realizar balanceamento de carga de requisições, ou seja, dada uma carga acima da
capacidade de processamento de um único servidor, verificar se a carga foi distribuída
igualmente em todos os Servidores IMS habilitados na rede.


      A taxa de utilização é dada pela média de requisições sendo atendidas pelo
componente CSCF, em relação à sua capacidade máxima de atendimento simultâneo de
requisições. Sendo assim, a taxa de utilização do CSCF será dada por:

  \begin{equation}
      U_{CSCF_{i}} = \dfrac{100 * mr}{sr}
  \end{equation}
  onde: 
  
  $U_{CSCF_{i}}$ é a taxa de utilização do componente CSCF no $i$-ésimo Servidor IMS.
  
  $mr$ é a média de requisições sendo atendidas pelo CSCF durante a simulação.
  
  $sr$ é o número máximo de requisições simultâneas cujo componente CSCF consegue
processar, ou seja, o número de execuções em paralelo de cada Servidor IMS.

      Considerando o modelo utilizado para as simulações, a média de requisições
sendo atendidas pode ser calculada utilizando-se o recurso
de \textit{continuous-time statistics} oferecido pelo simulador CPN. O simulador CPN
calcula a média (\textit{timeaveraged}) com base nas informações de tempo do modelo,
conforme descrito em \cite{cpn}. 

      A média baseada em tempo considera o intervalo entre duas observações como peso
para sua composição, e é dada por:

  \begin{equation}
      mr = 
      \dfrac{(\sum^{n-1}_{j=1} x_{j}(mt_{j+1}-mt_{j})) + x_{n}(mt-mt_{n})}
            {mt-mt_{1}}
  \end{equation}
  onde: 

  $n$ é o número de observações realizadas.
  
  $x_{j}$ é a $j$-ésima observação.
  
  $mt_{j}$ é o tempo do simulador no momento da observação $j$.
  
  $x_{n}$ é a última observação realizada.
  
  %$mt_{n}$ é o tempo do simulador no momento da observação $n$, ou
%seja, no momento da última observação.
  
  $mt$ é o tempo final do simulador, ou seja, a última marcação de
tempo do simulador. Essa variável difere da variável $mt_{n}$ pois o tempo do simulador
pode ter sido incrementado sem que tenha ocorrido uma observação.

  %$mt_{1}$ é o tempo do simulador no momento da primeira observação.


   Considerado o modelo CPN da arquitetura, a taxa de utilização do CSCF será obtidas com
base na média de marcações nos lugares \texttt{CSCF}, \texttt{INV} e \texttt{REG}.
A média de marcações será gerada pelo monitor \texttt{LoadCSCF}, conforme código
CPN-ML disponibilizado no Apêndice \ref{app:apendice-monitores}. 

   A existência de pelo menos uma marcação em um dos lugares \texttt{CSCF},
\texttt{INV} ou \texttt{REG}, indica que o CSCF está sendo utilizado.



 \subsubsection{Tempo médio de residência nas operações de Registro e Início de
Sessão}

      O tempo médio de residência indica o tempo de resposta nas operações de
registro (REGISTER) e início de sessão (INVITE), e são expressados por $R_{r}$ e $R_{s}$
respectivamente. 

      A métrica é dada por: 
   
   \begin{equation}
       R_{r} = 
       \dfrac{\sum^{C_{REGISTER}}_{j=1}(mt_{c_{REGISTER_{j}}} - mt_{s_{REGISTER_{j}}})}
             {C_{REGISTER}}
   \end{equation}
   
   \begin{equation}
       R_{s} = 
       \dfrac{\sum^{C_{INVITE}}_{j=1}(mt_{c_{INVITE_{j}}} - mt_{s_{INVITE_{j}}})}
             {C_{INVITE}}
   \end{equation}

   onde, 

   $C_{REGISTER}$ é o número de entidades (tuplas) de registro processadas.
   
   $C_{INVITE}$ é o número de entidades (tuplas) de início de
sessão processadas.

   $mt_{c_{REGISTER_{j}}}$ é o tempo do simulador no momento da chegada da $j$-ésima 
requisição de registro no sistema, ou seja, momento da execução de uma operação
\texttt{out()} representando a publicação de uma requisição REGISTER no LTS.

   $mt_{s_{REGISTER_{j}}}$ é o tempo do simulador no momento de saída da $j$-ésima
requisição de registro do sistema, ou seja, leitura de uma tupla realizada pelo
dispositivo cliente através da operação \texttt{in()}, cujo código de resposta indique a
finalização do processamento de registro.

   $mt_{c_{INVITE_{j}}}$ é o tempo do simulador no momento da chegada da $j$-ésima 
requisição de estabelecimento de sessão no sistema, ou seja, momento da execução de uma
operação \texttt{out()} representando a publicação de uma requisição INVITE no LTS.

   $mt_{s_{INVITE_{j}}}$ é o tempo do simulador no momento de saída da $j$-ésima
requisição de estabelecimento de sessão do sistema, ou seja, leitura de uma tupla
realizada pelo dispositivo cliente através da operação \texttt{in()}, cujo código de
resposta indique a finalização do processamento de estabelecimento de sessão.

   Com base no modelo CPN da arquitetura, as variáveis $mt_{c_{REGISTER_{j}}}$ e
$mt_{c_{INVITE_{j}}}$ serão obtidas no momento do disparo da transição \texttt{Create
Request}, e as variáveis $mt_{s_{REGISTER_{j}}}$ e $mt_{s_{INVITE_{j}}}$ serão obtidas no
momento do disparo da transição \texttt{Receive Response}. 

   Para calcular o intervalo foram definidos dois monitores, \texttt{SessionSetupDelay} e
\texttt{RegistrationDelay}, cujo código CPN-ML podem ser vistos no Apêndice
\ref{app:apendice-monitores}.

   Ambos os monitores estão associados à transição \texttt{Receive Response}, ou seja, a
cada disparo dessa transição o simulador CPN Tool irá executar os monitores para coletar o
intervalo de tempo de uma requisição específica. O monitor \texttt{SessionSetupDelay}
somente irá calcular o tempo de residência quando a requisição estiver com um valor
\texttt{ACK} (requisição aceita) e código de resposta \textit{r200} (com sucesso). O
monitor \texttt{RegistrationDelay} somente irá calcular o tempo de
residência quando a requisição for uma operação \texttt{REGISTER} e receber um código de
resposta \textit{r200}.

   Ao final da simulação, o simulador CPN Tool calcula a média de tempo com base nas
coletas de dados realizadas pelos monitores.


   %
   %
   %
   \subsubsection{Tempo médio de espera no LTS} 
 
   O tempo médio de espera no LTS indica o tempo em que as requisições permanecem em cada
LTS desde a sua publicação até a leitura pelo componente \textit{Events Processor}, e é
dado por:
   
   \begin{equation}
      E[w]_{LTS_{i}} =  \dfrac{\sum^C_{j=1}(mt_{in_{LTS_{i_{j}}}} -
mt_{out_{LTS_{i_{j}}}})} {C}
   \end{equation}
   
   onde: 

   $E[w]_{LTS_{i}}$ é o tempo médio de espera no LTS do $i$-ésimo Servidor IMS.

   $C$ é o número de tuplas publicadas em cada LTS.

   $mt_{out_{LTS_{i_{j}}}}$ é o tempo do simulador no momento da publicação da $j$-ésima
tupla no LTS do $i$-ésimo Servidor IMS.
   
   $mt_{in_{LTS_{i_{j}}}}$ é o tempo do simulador no momento da leitura da $j$-ésima
tupla do LTS do $i$-ésimo servidor IMS.
   

   Com base no modelo CPN da arquitetura, o parâmetro $mt_{out_{LTS_{i_{j}}}}$ será obtido
no momento do disparo da transição \texttt{OutC} e o parâmetro $mt_{in_{LTS_{i_{j}}}}$ 
será obtido no momento do disparo da transição \texttt{inLTS}.

   O intervalo de tempo de espera de cada tupla será calculado pelo monitor
\texttt{WaitingTimeLTS}, conforme código CPN-ML apresentado no Apêndice
\ref{app:apendice-monitores}. Ao final, o simulador CPN Tool calcula a média
de tempo de espera com base nas coletas de dados realizadas.
.
   %
   %
   %
   \subsubsection{Tempo médio de espera no DTS} 

   O tempo médio de espera no DTS indica o tempo em que as requisições permanecem no
espaço de tuplas distribuído, desde a sua publicação até a leitura pelo componente
\textit{Events Processor} de qualquer um dos Servidores IMS da rede. A métrica é
dado por:
   
   \begin{equation}
      E[w]_{DTS} = \dfrac{\sum^C_{j=1}(mt_{in_{DTS_{j}}} - mt_{out_{DTS_{j}}})}{C}
   \end{equation}

   onde: 

   $E[w]_{DTS}$ é o tempo médio de espera no DTS.

   $C$ é o número de tuplas publicadas.

   $mt_{out_{DTS_{j}}}$ é o tempo do simulador no momento da publicação da $j$-ésima
tupla no DTS.
   
   $mt_{in_{DTS_{j}}}$ é o tempo do simulador no momento da leitura da $j$-ésima tupla do
DTS.
   

   Com base no modelo CPN da arquitetura, o parâmetro $mt_{out_{DTS_{j}}}$ será obtido no
momento do disparo de uma das transições \texttt{out1}, \texttt{out2}, \texttt{out3},
\texttt{out4} ou \texttt{outDA} e o parâmetro $mt_{in_{DTS{j}}}$  será obtido no
momento do disparo da transição \texttt{inDTS} de cada um dos Servidores IMS.

   O intervalo de tempo de espera de cada tupla será calculado pelo monitor
\texttt{WaitingTimeDTS}, conforme código CPN-ML apresentado no Apêndice
\ref{app:apendice-monitores}. Ao final, o simulador CPN Tool calcula a média
de tempo de espera com base nas coletas de dados realizadas.


   %
   %
   %
   \subsubsection{Média de tuplas em espera no LTS}
   
   A média de tuplas no LTS irá indicar o número médio de tuplas em espera no espaço de
tuplas local de cada um dos Servidores IMS. Esse indicador é importante pois poderá ser
utilizado como parâmetro para cálculo da capacidade necessária de memória para o
Servidor IMS.
  
   Considerando o modelo temporizado utilizado para as simulações, a média de
tuplas no LTS será calculada utilizando-se o recurso de \textit{continuous-time
statistics} oferecido pelo simulador, conforme já utilizado para a métrica de Taxa de
Carga do CSCF. 

   Nesse sentido, a média de tuplas em espera no LTS é dada por:

  \begin{equation}
      E[n_{q}]_{LTS_{i}} = 
         \dfrac{(\sum^{n-1}_{j=1} x_{j}(mt_{j+1}-mt_{j})) + x_{n}(mt-mt_{n})}
            {mt-mt_{1}}
  \end{equation}
  onde: 

  $E[n_{q}]_{LTS_{i}}$ é a média de tuplas em espera no LTS do $i$-ésimo Servidor IMS.
  
  $n$ é o número de observações.
  
  $x_{j}$ é a $j$-ésima observação realizada.
  
  $mt_{j}$ é o tempo do simulador no momento da $j$-ésima observação.
  
  $x_{n}$ é a última observação realizada.
  
  %$mt_{n}$ é o tempo do simulador no momento da observação $n$, ou
%seja, no momento da última observação.
  
  $mt$ é o tempo final do simulador, ou seja, a última marcação de
tempo do simulador. Essa variável difere da variável $mt_{n}$ pois o tempo do simulador
pode ter sido incrementado sem que tenha ocorrido uma observação.

  %$mt_{1}$ é o tempo do simulador no momento da primeira observação.
  
  
  A coleta de dados para a média de tuplas em espera no DTS será feita pelo monitor
\texttt{AvgTuplesLTS}, conforme código CPN-ML apresentado no Apêndice
\ref{app:apendice-monitores}. Em cada observação, o monitor conta o número de
marcações existente nos lugares \texttt{LTSi}, \texttt{NiC} e \textit{NiD}.
É importante destacar que existirá um monitor \texttt{AvgTuplesLTS} para cada Servidor
IMS. Ao final, cada um dos monitores gera a média para o seu respectivo LTS com base no
total acumulado em cada observação. 

 
   %
   %
   %
   \subsubsection{Média de tuplas em espera no DTS}
 
   A média de tuplas no DTS irá indicar o número médio de tuplas em espera no espaço de
tuplas distribuído. Esse indicador é importante pois poderá ser utilizado como parâmetro
para cálculo da capacidade necessária de memória compartilhada ou espaço em disco para o
DTS.
  
   Considerando o modelo temporizado utilizado para as simulações, a média de
tuplas no DTS será calculada utilizando-se o recurso de \textit{continuous-time
statistics} oferecido pelo simulador, conforme utilizado na média de tuplas em espera
no LTS e na taxa de utilização do CSCF. 

   Nesse sentido, a média de tuplas em espera no DTS é dada por:

  \begin{equation}
      E[n_{q}]_{DTS} = 
         \dfrac{(\sum^{n-1}_{j=1} x_{j}(mt_{j+1}-mt_{j})) + x_{n}(mt-mt_{n})}
            {mt-mt_{1}}
  \end{equation}
  onde: 

  $E[n_{q}]_{DTS}$ é a média de tuplas em espera no DTS.
  
  $n$ é o número de observações.
  
  $x_{j}$ é a $j$-ésima observação realizada.
  
  $mt_{j}$ é o tempo do simulador no momento da $j$-ésima observação.
  
  $x_{n}$ é a última observação realizada.
  
%  $mt_{n}$ é o tempo do simulador no momento da observação $n$, ou
%seja, no momento da última observação.
  
  $mt$ é o tempo final do simulador, ou seja, a última marcação de
tempo do simulador. Essa variável difere da variável $mt_{n}$ pois o tempo do simulador
pode ter sido incrementado sem que tenha ocorrido uma observação.

%  $mt_{1}$ é o tempo do simulador no momento da primeira observação.
  
  
  A coleta de dados para a média de tuplas em espera no DTS será feita pelo monitor
\texttt{AvgTuplesDTS}, conforme código CPN-ML apresentado no Apêndice
\ref{app:apendice-monitores}. Em cada observação, o monitor conta o número de
marcações existente nos lugares \texttt{DTS}, \texttt{B1}, \texttt{D1},
\texttt{E1} e \texttt{H1}. Ao final, ele gera a média com base no total acumulado em
cada observação. 

   %
   %
   %
   \subsubsection{Vazão do sistema} 
 
   A Vazão do sistema, identificada por $V$, indica o número de requisições por
segundo processada pelo sistema em diferentes condições de carga. 
  
   A vazão é dada por
  
   \begin{equation}
      V = \dfrac{C}{mt}
   \end{equation}
   
   onde: 
      
   $C$ é o número de entidades processadas (requisições atendidas).
  
   $mt$ é o tempo do simulador ao final da simulação. 
   
   O parâmetro $C$ é um valor definido no cenário de simulação como sendo o número de
dispositivos conectados na rede. Para fins de simulação, o valor de $C$ foi definido em
25000.

   O parâmetro $mt_{end}$ é gerado pelo simulador e ao final da simulação, e apresentado
no relatório de coleta de dados.

   %
   %
   %
   \subsubsection{Escalabilidade} 
 
   Em geral, a escalabilidade é a habilidade do sistema operar de forma
eficiente e com qualidade de serviço à medida em que se aumenta a carga de
trabalho. Em \cite{scalability} foi apresentado um arcabouço de métricas e
estratégias para avaliação de escalabilidade. 

  No contexto deste trabalho consideramos a análise através de três
abordagens, abordagem baseada na vazão do sistema ($V$), abordagem
baseada nos tempos de resposta ($R_{r}$ e $R_{s}$) e abordagem baseada na
produtividade ($F$).

  \begin{description}
 
    % 
    % baseado na vazao
    %
    \item[Análise com base na vazão do sistema]

      A escalabilidade com base na vazão do sistema será demonstrada a partir da
simulação do sistema completo (todos os Servidores IMS habilitados) exposto a diferentes
condições de carga. O fator de escalabilidade será obtida pela razão entre vazão
($V$) e carga ($\lambda$), e é dada por 

 \begin{equation}\label{eq:escalaVazao}
      \psi = \dfrac{V}{\lambda}
 \end{equation}

      Considerando que o fator de escalabilidade é a razão entre vazão e carga, o sistema
se mantém escalável enquanto o fator de escalabilidade for mantido com diferentes cargas.

      Exemplo: supondo uma execução com $\lambda=100 req/seg$ e $V=100 req/seg$, tem-se um
fator de escalabilidade $\psi=1$; na próxima execução com $\lambda=200 req/seg$ e
$V=120 req/seg$, tem-se um fator de escalabilidade $\psi=0.6$. Neste caso, pode-se
afirmar que para $\lambda=200 req/seg$ o sistema não escalou. 

      Nesse sentido, considerando que as simulação se baseou em uma rede com quatro
Servidores IMS, o objetivo da abordagem baseada na vazão é indicar o limite de carga em
que a rede se mantém escalável, considerando apenas os quatro Servidores IMS.


    % 
    % baseado no tempo de resposta
    % 
    \item[Análise com base em tempos de resposta]

      Para análise com base no tempo de resposta serão utilizadas as duas
métricas definidas a seguir:

   \begin{enumerate}
    % 
    % speedup
    %
    \item Speedup ($S$), mede a taxa de crescimento de trabalho realizado com
$p$ Servidores IMS, comparado ao trabalho realizado com apenas um Servidor IMS. O SpeedUp
é dado por
        \begin{equation}\label{eq:speedup}
           Sp = \dfrac{T_{1}}{T_{p}}
        \end{equation}
        onde: 
        
        $T_{1}$ é o tempo de resposta $R$ para simulação com apenas um Servidor IMS
habilitado.
        
        $T_{p}$ é o tempo de resposta $R$ para simulação com $p$ Servidores IMS
habilitados.

    O SpeedUp ideal ou SpeedUp linear é obtido quando $S_{p} = p$.
 
    Considerando que existe um percentual ($pc_{r}$) de requisições de registro
e um percentual ($pc_{s})$ de requisições de início de sessão, utilizaremos um
tempo médio geral de residência ($R$) que é a média ponderada dada por

 \begin{equation}
      R = \dfrac{(R_{r} * peso_{r}) + (R_{s} * peso_{s})}{100}
 \end{equation}
 onde: 
 
 $R_{r}$ é o tempo médio de residência nas operações de registro

 $R_{s}$ é o tempo médio de residência nas operações de início de sessão
 
 $peso_{r}$ é o peso do tempo médio de residência nas operações de registro com
base no percentual ($pc_{r}$) de requisições de registro definidos na
simulação.

 $peso_{s}$ é o peso do tempo médio de residência nas operações de início de
sessão com base no percentual ($pc_{s}$) de requisições de início de sessão definidos na
simulação.


    %
    % eficiencia
    %
    \item Eficiência ($E$) é a taxa de trabalho por número de Servidores IMS habilitados,
definido por
        \begin{equation}\label{eq:eficiencia}
           Ep = \dfrac{S_{p}}{p}
        \end{equation}
        onde:      
     
        $S_{p}$ é o valor obtido em (\ref{eq:speedup})
        
        $p$ é o número de Servidores IMS habilitados.

      Valores são obtidos entre 0.0 e 1.0, sendo maior a eficiência à medida em
que se aproxima de 1.0, neste caso, SpeedUp linear.

   \end{enumerate}

    %
    % escalabilidade
    %
    \item[Escalabilidade baseada na Produtividade]

      Finalizando a análise de escalabilidade, foi adotada a abordagem baseada
em produtividade, apresentada em \cite{scalability}. O sistema é tido como
escalável à medida em que a produtividade é mantida com o aumento da carga.  

      Para a métrica baseada em produtividade, a equação geral de escalabilidade é
dada por 

     \begin{equation}\label{eq:produtividade}
      \psi(p_{1},p_{2}) = \dfrac{F(p_{2})}{F(p_{1})}
     \end{equation}
     
     onde:
     
     $\psi(p_{1},p_{2})$ é o fator de escalabilidade partindo do cenário 1 para o cenário
2. 
     
     $F(p_{1})$ é a produtividade do sistema para o cenário $1$.
     
     $F(p_{2})$ é a produtividade do sistema para o cenário $2$.
     
     
     A produtividade é dada por:
     
     \begin{equation}
      F(p) = \dfrac{V_{p}*f_{QoS_{p}}(\sigma_{1},..,\sigma_{n})}{CT_{p}}
     \end{equation}
     
     onde,
     
     $V_{p}$ é a vazão do sistema para o cenário de simulação com $p$ Servidores IMS.
     
     $f_{QoS_{p}}(\sigma_{1},..,\sigma_{n})$ é uma função de QoS quando considerado $p$
Servidores IMS. Nesse caso, a qualidade de serviço será definida em função de uma lista de
parâmetros, representados por $\sigma_{1},..,\sigma_{n}$, definidos estrategicamente de
acordo com a característica do sistema.

     $CT_{p}$ é o custo de execução proporcional considerando $p$ Servidores IMS, também
podendo ser expressado como a relação custo/benefício.

      Para efeito de aplicação do método da produtividade na análise da arquitetura
baseada em espaço de tuplas, a função de QoS $f_{QoS_{p}}(\sigma_{1},..,\sigma_{n})$ será
calculada com base no tempo médio de resposta do sistema, definido anteriormente por $R$. 

      Nesse caso, a função de QoS adotada para análise é dada por:

     \begin{equation}\label{eq:prod-qos}
      f_{QoS_{p}}(\sigma) = \dfrac{1}{(R_{p}/\hat{R})}
     \end{equation}
     
      onde, 
      
      $\sigma$ é o parâmetro utilizado para definir qualidade de serviço, no caso, o
tempo de resposta.
      
      $R_{p}$ é o tempo médio de resposta quando considerado $p$ Servidores IMS
habilitados.

      $\hat{R}$ é um tempo médio de resposta alvo, ou seja, o tempo médio que se espera
atingir como aceitável. 


      Também para efeito de aplicação do método, o custo é dado por:
      
      \begin{equation}\label{eq:custo}
            CT = \begin{cases} 
                  1, & \mbox{quando } p=1 \mbox{ ou seja, um Servidor IMS} \\ 
                  k*CT_{(p-1)}, & \mbox{quando } p>1 
                \end{cases}
      \end{equation}
      
      onde, $k$ é uma constante que multiplica o custo a cada Servidor IMS adicionado à
rede.

      O sistema é considerado escalável de $p_{1}$ para $p_{2}$ se $\psi \geq 1$.
Adicionalmente, é possível definir um valor mínimo limite (\textit{threshold}
$\tau$) para indicar escalabilidade.  Nesse caso, o sistema é tido como
escalável se $\psi \geq \tau$.

   %% incluir no cenario  $\hat{R}$.

  \end{description}


%
% Análise cenario
%
\subsection{Cenário Base}

     A análise de desempenho da arquitetura assume um cenário típico de registro de
dispositivos e estabelecimento de sessão entre dispositivos localizados em dois domínios
de rede, Domínio A (\textit{Home Network}) e Domínio B (\textit{Visited Network}),
conforme utilizado por \cite{QPN-IMS}.

     A Figura \ref{fig-cenario} ilustra esse cenário considerando uma
arquitetura IMS padrão.
     
   \begin{figure}[ht]
     \centering
     \includegraphics[scale=0.8]{figuras/fig-cenario.png}
     \caption{Cenário para análise de desempenho e construção dos modelos CPN}
     \label{fig-cenario}
   \end{figure} 
   
    Com base nesse modelo, as operações na rede IMS podem ocorrer da seguinte forma:
    
    \begin{enumerate}
     \item Um dispositivo localizado no Domínio A, sendo esse domínio o seu \textit{Home
Network}, enviando uma requisição de registro. Nesse caso, a requisição é feita
localmente, uma vez que o dispositivo está localizado dentro de sua rede, Domínio A.

     \item Um dispositivo localizado no Domínio B, sendo esse domínio a sua
\textit{Visited Network}, enviando uma requisição de registro. Nesse caso, o dispositivo
envia a requisição para a rede em que está localizado no momento, no caso o Domínio B, e
então os Servidores IMS do Domínio B repassam a requisição para o Domínio A.

     \item Dispositivo localizado no Domínio A (\textit{Home Network}) tentando
estabelecer uma sessão com dispositivos da própria rede.

     \item Dispositivo localizado no Domínio A (\textit{Home Network}) tentando
estabelecer uma sessão com dispositivos localizados no Domínio B.

     \item Dispositivo localizado no Domínio B (\textit{Visited Network}) tentando
estabelecer uma sessão com dispositivos da sua rede Domínio A, ou da rede em que está
localizado, Domínio B

    \end{enumerate}

% 
%    As Figuras \ref{fig:ims-registration} e \ref{fig:ims-sessionsetup} ilustram a
% sequência de troca de mensagens mensagens para as operações de registro e
% estabelecimento de conforme discutido em \cite{IMSTrafficModel} e também apresentado
% anteriormente.
% 
%    \begin{figure}[ht]
%      \centering
%      \includegraphics[scale=0.55]{figuras/fig-ims-registration.png}
%      \caption{Fluxo de mensagem para registro de dispositivos na arquitetura IMS
% \cite{IMSTrafficModel}}
%      \label{fig:ims-registration}
%    \end{figure} 
% 
%    \begin{figure}[ht]
%      \centering
%      \includegraphics[scale=0.8]{figuras/fig-ims-sessionsetup.png}
%      \caption{Fluxo de mensagem para estabelecimento de sessão na arquitetura
% IMS \cite{IMSTrafficModel}}
%      \label{fig:ims-sessionsetup}
%    \end{figure} 
% 
% 
%      Para o contexto da arquitetura baseada em espaço de tuplas o fluxo de
% mensagens é basicamente o mesmo, uma vez que a premissa da arquitetura é manter
% a semântica SIP e IMS. A diferença é que ao invés de realizar uma requisição
% diretamente ao P-CSCF como mostra a Figura \ref{fig-cenario}, o dispositivo irá
% publicar uma Tupla no LTS a qual estiver conectado, e todo o processamento e
% troca de mensagens entre dispositivos e CSCF será feito através do espaço de
% tuplas.


     A simulação foi dividida em três etapas: 
     
     \begin{enumerate}
      \item A primeira etapa (Simulação 01) considerou uma carga fixa de 1200 req/seg
(acima de 4 milhões por hora), sendo disparadas por dispositivos localizados no Domínio B
e dispositivos localizados no Domínio A conectados a um único Servidor IMS, ou seja,
apenas um dos Servidores IMS recebe as requisições. Nessa etapa, a simulação inicia com
um Servidor IMS habilitado (o que recebe as requisições), e a cada execução da simulação
um novo Servidor IMS é habilitado (de 1 a 4 servidores IMS habilitados).

      \item A segunda etapa (Simulação 02) considerou a rede completa, com os quatro
Servidores IMS habilitados, variando a carga de requisições de 100 a 1150 req/seg, sendo
disparadas por dispositivos localizados no Domínio B e no Domínio A com os quatro
Servidores IMS recebendo requisições de maneira não uniforme (número de disparos
diferentes para cada Servidor IMS). 
   

      \item Na terceira etapa (Simulação 03) foi realizada a simulação da rede IMS
padrão, com o objetivo de comparar os resultados obtidos com os resultados obtidos na
simulação da arquitetura baseada em espaço de tuplas. O modelo CPN para a arquitetura
padrão pode ser analisado na Figura \ref{fig:cpn-rede-default}, no apêndice
\ref{app:apendice-modelo-cpn-default}. 

     \end{enumerate}

      Um parâmetro importante utilizado é o número de requisições de registro (REGISTER) e
requisições de estabelecimento de sessão (INVITE); para este parâmetro foi utilizado uma
distribuição uniforme de 60\% para REGISTER e 40\% para INVITE, seguindo os estudos sobre
redes IMS apresentados em \cite{SIPTraffic}.

      O intervalo de chegada de requisições segue uma distribuição de Poisson, e os demais
intervalos de tempo (atrasos na rede, nas operações de escrita e leitura e o tempo de
processamento dos elementos) seguem distribuições exponenciais, conforme funções CPN-ML
apresentadas na sessão \ref{cpn-redesims}.


      A Tabela \ref{tbl:simulation-param} apresenta um resumo dos tempos utilizados nas
simulações. 

\begin{table}[htbp]
    \centering
    \caption{Parâmetros utilizados durante as simulações }
    \label{tbl:simulation-param}
    %\vspace{0.5cm}
    %\hspace{0.5cm}  
    \begin{tabular}{|p{4.0cm}|p{7.0cm}|p{3.0cm}|}
        \hline \textbf{Parâmetro/Função}  & \textbf{Descrição}    & \textbf{Valor}\\
        \hline RANDelay             & Atraso no acesso à rede IMS & 100ms\\
        \hline LTSAccessDelay       & Atraso no acesso ao LTS     & 10ms \\
        \hline DTSAccessDelay       & Atraso no acesso ao DTS     & 15ms \\
        %\hline DomainB delay        & tempo de processamento no Domínio B & 160ms\\
        \hline InterDomainDelay     & Atraso na comunicação entre Domínios A e B & 25ms\\
        \hline HSSQueryTime         & Tempo gasto para consultar o HSS  & 2ms e 15ms \\
        \hline CSCFProcessingTime   & Tempo de processamento do CSCF    & 3ms \\
        \hline InviteTargetUEDelay  & Atraso na comunicação com o UE destino & 50ms e
160ms \\
        
        
        \hline
    \end{tabular}
   \end{table}
   
%
% Resultados
%
\subsection{Resultados}


    %
    %
    %
    \subsubsection{Simulação 01 - Variação do número de Servidores IMS habilitados}

      O primeiro cenário de simulação teve como objetivo a análise de aspectos de
escalabilidade da arquitetura baseada em espaço de tuplas, considerando uma taxa de
chegada ($\lambda$) de 1200 requisições por segundo, variando o número de Servidores IMS
habilitados. As tabelas \ref{tbl:res-sim01a} e \ref{tbl:res-sim01b} mostram um
resumo dos resultado obtidos. 

\begin{table}[htbp]
    \centering
    \caption{Resultados da Simulação 01 (a)}
    \label{tbl:res-sim01a}
   
\begin{tabular}{|c|c|c|c|c|c|c|}
        \hline $No. Serv$  & $U_{CSCF_{1}}$ & $U_{CSCF_{2}}$ & $U_{CSCF_{3}}$ &
$U_{CSCF_{4}}$  & $Rr$   & $Rs$  \\
        \hline 1 & 98,29\% & ---       & ---    & ---    & 13s    & 26s \\
        \hline 2 & 95,91\% & 91,53\%   & ---    & ---    & 3,5s   & 7,8s \\
        \hline 3 & 81,60\% & 71,97\%   & 69,96\%& ---    & 0,98s  & 2,3s \\
        \hline 4 & 73,61\% & 49,73\%   & 47,56\%& 50,66\%& 0,45s  & 1,1s \\
        \hline
    \end{tabular}
   \end{table}

\begin{table}[htbp]
    \centering
    \caption{Resultados da Simulação 01 (b)}
    \label{tbl:res-sim01b}
   
   \begin{tabular}{|c|c|c|c|c|c|c|c|}
        \hline $No. Serv$  & $E[w]_{DTS}$ & $E[n_{q}]_{DTS}$ & $V (req/seg)$ & $\psi (Sp)$
& $Ep$ & $\psi(F) k=2$  & $\psi(F) k=1.5$ \\
        \hline 1 & 3779ms  & 15704  & 440    & 1      & 1      & 1   & 1   \\
        \hline 2 & 940ms   &  3752  & 829    & 1,88   & 0,94   & 3,4 & 4,5 \\
        \hline 3 & 189ms   &   760  & 909    & 2,06   & 0,69   & 6,5 & 11,3 \\
        \hline 4 & 33ms    &   130  & 919    & 2,09   & 0,52   & 9,3 & 16,2 \\
        \hline
    \end{tabular}
   \end{table}
%      Os gráficos apresentados nas Figuras \ref{graf01:vazao},
%\ref{graf01:tempoResposta},
%\ref{graf01:speedup}, \ref{graf01:escala}, \ref{graf01:mediaTupla},
%\ref{graf01:tempoEspera} e \ref{graf01:utilizacao} apresentam os resultados.

      Como pode-se observar nos gráficos das Figuras \ref{graf01:vazao} e
\ref{graf01:tempoResposta}, à medida em que se aumenta o número de Servidores IMS na rede,
aumenta a vazão do sistema e diminui o tempo de resposta das operações de registro e
estabelecimento de sessão. Quando executado com apenas um Servidor IMS na rede, o tempo de
resposta para operações de registro e estabelecimento de sessão é de aproximadamente 14s e
26s respectivamente, ao passo que na execução com 4 Servidores IMS os tempos de
registro e estabelecimento de sessão caem para 0,45s e 1,10s respectivamente.

        \begin{figure}[h!]
         \centering
         \includegraphics[scale=0.6]{graficos/graf01-vazao.png}
         \caption{Simulação 01 - Vazão X Número de Servidores IMS}
         \label{graf01:vazao}
        \end{figure}

        \begin{figure}[h!]
         \centering
         \includegraphics[scale=0.6]{graficos/graf01-tempoResposta.png}
         \caption{Simulação 01 - Tempos de Resposta X Número de Servidores IMS}
         \label{graf01:tempoResposta}
        \end{figure}

      As gráficos das  Figuras \ref{graf01:speedup} e \ref{graf01:escala} apresentam os
resultados de escalabilidades obtidos. 

      Para esse cenário de simulação foram utilizadas duas abordagens para avaliação da
escalabilidade: escalabilidade com base no SpeedUp e Eficiência, conforme definidos pelas
equações \eqref{eq:speedup} e \eqref{eq:eficiencia}; escalabilidade com base na equação
de produtividade \eqref{eq:produtividade}.

      Na Figura \ref{graf01:speedup} é observado a escalabilidade com base no SpeedUp
($Sp$) e Eficiência ($Ep$). É importante notar que para o cenário com carga de 1200
req/seg o equilíbrio entre SpeedUp e Eficiência ocorre com a utilização de dois e três
Servidores IMS. Esse resultado demonstra que para o cenário apresentado, até três
Servidores IMS na rede seriam suficientes, uma vez que o SpeedUp aumenta e a Eficiência se
mantém em relação à execução com apenas um Servidor IMS. 

        \begin{figure}[h!]
         \centering
         \includegraphics[scale=0.6]{graficos/graf01-speedup.png}
         \caption{Simulação 01 - Escalabilidade e Eficiência com base no SpeedUp}
         \label{graf01:speedup}
        \end{figure}


      O gráfico da Figura \ref{graf01:escala} apresenta a escalabilidade com base na
equação de produtividade \eqref{eq:produtividade}. Para efeito de demonstração da equação
de produtividade, utilizamos os seguintes parâmetros:  

\begin{itemize}
   \item Para a função de QoS \eqref{eq:prod-qos}, foi adotado como base um tempo de
resposta médio aceitável de 700ms, ou seja, o índice de QoS aumenta à medida em que
o tempo de resposta obtido com a simulação tende a 700ms. O tempo de resposta limitante
de 700ms foi adotado com base na execução da simulação com apenas uma requisição, ou
seja, foi o melhor tempo alcançado com os modelos CPN adotados\footnote{O valor de 700ms
foi adotado para efeito de demonstração da abordagem. Para uma análise mais precisa, é
necessária a definição de uma função de QoS que utilize outras variáveis, além do tempo de
resposta.}. 

   \item Para o custo por unidade de processamento \eqref{eq:custo} foram considerados
dois valores para a variável $k$: $k=2$ representando um custo adicional de 100\%
por adição de Servidor e $k=1.5$ representando um custo adicional de 50\% por adição de
Servidor IMS. Nesses casos, para cada Servidor IMS adicionado à rede o custo aumenta 100\%
ou 50\% em relação ao custo anterior\footnote{Os valores de 50\% e 100\% foram adotados
para efeito de demonstração da abordagem. Para uma análise mais precisa, é necessário um
estudo mais preciso de custo por unidade de processamento considerando aspectos de
hardware, custo de gerenciamento da infraestrutura e custo operacional.}.

\end{itemize}

      Com os parâmetros definidos anteriormente, pode-se observar a comprovação da
escalabilidade tanto para custo de 50\% quanto para custo de 100\% por Servidor IMS. Esse
comportamento ocorre devido à melhora nos tempos de resposta que sobrepõem o custo
adicional por Serivodor IMS.

        \begin{figure}[h!]
         \centering
         \includegraphics[scale=0.6]{graficos/graf01-escala.png}
         \caption{Simulação 01 - Escalabilidade com base na equação de produtividade}
         \label{graf01:escala}
        \end{figure}


     Os gráficos das Figuras \ref{graf01:mediaTupla} e \ref{graf01:tempoEspera} mostram a
média de tuplas e o tempo de espera no DTS. Nota-se que à medida em que aumenta-se o
número de Servidores IMS na rede, o tempo de espera reduz significativamente, reduzindo
também a média de tuplas em espera durante a simulação.

        \begin{figure}[h!]
         \centering
         \includegraphics[scale=0.6]{graficos/graf01-mediaTuplasDTS.png}
         \caption{Simulação 01 - Média de Tuplas no DTS}
         \label{graf01:mediaTupla}
        \end{figure}

        \begin{figure}[h!]
         \centering
         \includegraphics[scale=0.6]{graficos/graf01-tempoEsperaDTS.png}
         \caption{Simulação 01 - Tempo de Espera no DTS}
         \label{graf01:tempoEspera}
        \end{figure}


     Por fim, uma constatação importante é a capacidade de balanceamento de carga do
sistema realizado pelo componente \textit{Events Processor} (ver Figura
\ref{fig:sipspace}). Essa observação pode ser feita no gráfico da Figura
\ref{graf01:utilizacao}, que apresenta a utilização de cada Servidor IMS da rede. 

     \begin{figure}[h!]
         \centering
         \includegraphics[scale=0.6]{graficos/graf01-utilizacao.png}
         \caption{Simulação 01 - Taxa de utilização do CSCF por Servidor IMS Habilitado}
         \label{graf01:utilizacao}
      \end{figure}

      Quando executado com apenas um Servidor IMS na rede, a taxa de carga média do CSCF é
de 98\%, ou seja, ocorre uma saturação do sistema. Quando executado com dois Servidores
IMS na rede, a carga é igualmente distribuída, ainda que com uma taxa média de utilização
de 95\%. À medida em que são habilitados três e quatro Servidores IMS, observa-se a
distribuição da carga de trabalho.

     A arquitetura apresentada neste trabalho não depende de nenhum esquema de
balanceamento de carga externo. Ao chegar uma requisição (e.g uma tupla publicada no
LTS), o \textit{Events Processor} verifica a carga do CSCF; caso este não tenha
capacidade para processar a requisição, o \textit{Events Processor} publica a requisição
no DTS para que qualquer Servidor IMS da rede com capacidade ociosa possa realizar o
processamento. 


    %
    %
    %
    \subsubsection{Simulação 02 - Variação da Carga}

     O segundo cenário de simulação teve como objetivo a análise do comportamento do
sistema em diferentes condições de carga. As tabelas \ref{tbl:res-sim02a},
\ref{tbl:res-sim02b}, \ref{tbl:res-sim02c} e \ref{tbl:res-sim02d} apresentam um resumo
dos resultados obtidos nas simulações.

   \begin{table}[h!]
      \centering
      \caption{Resultados da Simulação 02 (a)}
      \label{tbl:res-sim02a}
      \begin{tabular}{|c|c|c|c|c|c|c|}
        \hline $\lambda (req/seg)$ & $U_{CSCF_{1}}$ & $U_{CSCF_{2}}$ & $U_{CSCF_{3}}$ &
$U_{CSCF_{4}}$  & $Rr$   & $Rs$  \\
        \hline 100 & 11,43\% & 25,71\% & 20,00\% & 21,43\%& 0,34s & 0,93s \\
        \hline 200 & 20,00\% & 51,43\% & 37,14\% & 40,00\%& 0,34s & 0,93s \\
        \hline 400 & 58.73\% & 89,44\% & 60,41\% & 69,29\%& 0,72s & 1,90s \\
        \hline 520 & 78,57\% & 92,86\% & 82,86\% & 85,71\%& 1,82s & 4,48s \\
        \hline 676 & 81,43\% & 92,83\% & 87,14\% & 88,57\%& 2,86s & 6,33s \\
        \hline 879 & 81,43\% & 91,43\% & 85,71\% & 87,14\%& 3,77s & 7,61s \\
        \hline 1142 & 82,86\% & 93,57\% & 87,43\% & 88,14\%& 4,50s & 8,55s \\
        \hline
      \end{tabular}
   \end{table}

   
   \begin{table}[h!]
      \centering
      \caption{Resultados da Simulação 02 (b)}
      \label{tbl:res-sim02b}
      \begin{tabular}{|c|c|c|c|c|}
        \hline $\lambda (req/seg)$ & $E[w]_{DTS}$ & $E[n_{q}]_{DTS}$ & $V (req/seg)$ &
$\psi (V)$\\
        \hline 100   & 36ms  & 10   & 308  & 3,1 \\
        \hline 200   & 36ms  & 19   & 601  & 3,0 \\
        \hline 400   & 130ms & 688  & 1157 & 2,9 \\
        \hline 520   & 469ms & 3411 & 1408 & 2,7 \\
        \hline 676   & 756ms & 5665 & 1479 & 2,2 \\
        \hline 879   & 926ms & 6766 & 1488 & 1,7 \\
        \hline 1142  & 983ms & 7255 & 1453 & 1,3 \\
        \hline
      \end{tabular}
   \end{table}


   \begin{table}[h!]
      \centering
      \caption{Resultados da Simulação 02 (c)}
      \label{tbl:res-sim02c}
      \begin{tabular}{|c|c|c|c|c|}
        \hline $\lambda (req/seg)$ & $E[w]_{LTS_{1}}$ & $E[w]_{LTS_{2}}$ &
$E[w]_{LTS_{3}}$ & $E[w]_{LTS_{4}}$  \\
        \hline 100   & 20ms  & 19ms   & 19ms  & 20ms \\
        \hline 200   & 20ms  & 20ms   & 20ms  & 20ms \\
        \hline 400   & 22ms  & 21ms   & 23ms  & 22ms \\
        \hline 520   & 23ms  & 25ms   & 24ms  & 24ms \\
        \hline 676   & 27ms  & 26ms   & 26ms  & 27ms \\
        \hline 879   & 67ms  & 233ms  & 72ms  & 174ms \\
        \hline 1142  & 148ms & 566ms  & 204ms & 428ms \\
        \hline
      \end{tabular}
   \end{table}


   \begin{table}[h!]
      \centering
      \caption{Resultados da Simulação 02 (d)}
      \label{tbl:res-sim02d}
      \begin{tabular}{|c|c|c|c|c|}
        \hline $\lambda (req/seg)$ & $E[n_{q}]_{LTS_{1}}$ & $E[n_{q}]_{LTS_{2}}$ &
$E[n_{q}]_{LTS_{3}}$ & $E[n_{q}]_{LTS_{4}}$ \\
        \hline 100   & 3  & 11  & 7   & 9   \\
        \hline 200   & 6  & 22  & 14  & 17  \\
        \hline 400   & 11 & 42  & 24  & 32  \\
        \hline 520   & 14 & 55  & 30  & 40  \\
        \hline 676   & 16 & 59  & 33  & 45  \\
        \hline 879   & 30 & 312 & 70  & 191 \\
        \hline 1142  & 56 & 766 & 173 & 443 \\
        \hline
      \end{tabular}
   \end{table}


%As Figuras \ref{graf02:tempoResposta},
%\ref{graf02:tempoResposta95}, \ref{graf02:mediaTupla}, \ref{graf02:tempoEspera},
%\ref{graf02:vazao}, \ref{graf02:escalaVazao} e \ref{graf02:utilizacao} mostram os
%resultados obtidos.

      Como pode-se observar na Figura \ref{graf02:tempoResposta}, os tempos de resposta
das requisições de registro e estabelecimento de sessão permanecem estáveis até uma taxa
de chegada de 400 req/seg (1.440.000 req/hora), um valor extremamente alto comparado aos
resultados obtidos em \cite{QPN-IMS}.

        \begin{figure}[h!]
         \centering
         \includegraphics[scale=0.6]{graficos/graf02-tempoResposta.png}
         \caption{Simulação 02 -Tempos de resposta por taxa de chegada}
         \label{graf02:tempoResposta}
        \end{figure}

      Em complemento, o gráfico da Figura \ref{graf02:tempoResposta95} mostra o intervalo
de confiança da medida obtida nos tempos de resposta, considerando 95\% das requisições.

        \begin{figure}[h!]
         \centering
         \includegraphics[scale=0.6]{graficos/graf02-tempoRespostaConfidence.png}
         \caption{Simulação 02 - Tempos de resposta por taxa de chegada (95\%)}
         \label{graf02:tempoResposta95}
        \end{figure}


     Os gráficos das Figuras \ref{graf02:mediaTupla} e \ref{graf02:tempoEspera} mostram
a média de tuplas e o tempo de espera nos LTSs e no DTS durante a simulação. Assim como o
sistema se mantém estável até uma taxa de chegada de 400 req/seg, o mesmo
comportamento pode ser observado em relação à média de tuplas no espaço e ao tempo de
espera no espaço de tuplas para uma requisição ser processada. Uma observação importante é
que o aumento do tempo de espera e da média de tuplas é maior no DTS. Esse comportamento
ocorre em função do balanceamento de carga realizado pelo \textit{Events Processor}.

        \begin{figure}[h!]
         \centering
         \includegraphics[scale=0.6]{graficos/graf02-mediaTuplaEspaco.png}
         \caption{Simulação 02 - Média de tupla no espaço por taxa de chegada}
         \label{graf02:mediaTupla}
        \end{figure}

        \begin{figure}[h!]
         \centering
         \includegraphics[scale=0.6]{graficos/graf02-tempoEsperaEspaco.png}
         \caption{Simulação 02 - Tempo de espera no espaço por taxa de chegada}
         \label{graf02:tempoEspera}
        \end{figure}


     Comparando esse resultados com os resultados da simulação anterior apresentados nos
gráficos das Figuras \ref{graf01:mediaTupla} e \ref{graf01:tempoEspera}, é possível
afirmar que aumentando o número de Servidores IMS na rede a carga do DTS será distribuída,
reduzindo o tempo de espera e, consequentemente, reduzindo os tempos de resposta.


      O gráfico da Figura \ref{graf02:vazao} mostra a vazão do sistema à medida em que se
aumenta a taxa de chegada. Pode-se observar que a vazão do sistema aumenta até uma carga
de aproximadamente 500 req/seg. 

        \begin{figure}[h!]
         \centering
         \includegraphics[scale=0.6]{graficos/graf02-vazao.png}
         \caption{Simulação 02 - Vazão por taxa de chegada}
         \label{graf02:vazao}
        \end{figure}

      O gráfico da Figura \ref{graf02:escalaVazao} mostra a escalabilidade com base na
vazão do sistema, conforme definido na equação \eqref{eq:escalaVazao}. Essa abordagem
considera o sistema escalável enquanto o índice se mantiver estável em cada cenário de
execução. Como pode-se observar, até uma carga de aproximadamente 600
req/seg, o índice de escalabilidade se mantém em 3, ou seja, a vazão do sistema aumentou
na mesma proporção que a taxa de chegada. 

        \begin{figure}[h!]
         \centering
         \includegraphics[scale=0.6]{graficos/graf02-escalaVazao.png}
         \caption{Simulação 02 - Índice de escalabilidade com base na vazão}
         \label{graf02:escalaVazao}
        \end{figure}     

      Com as métricas de vazão, escalabilidade e comportamento do espaço de tuplas,
podemos concluir que o sistema é escalável. Porém para cargas acima de 600 req/seg seria
necessário adicionar Servidores IMS, ampliando a capacidade de processamento da rede.

      Finalizando a Simulação 02 , pode-ser observar no gráfico da Figura
\ref{graf02:utilizacao} a distribuição da taxa de carga entre todos Servidores IMS da
rede.

     \begin{figure}[h!]
         \centering
         \includegraphics[scale=0.5]{graficos/graf02-utilizacao.png}
         \caption{Simulação 02 - Taxa de carga do CSCF}
         \label{graf02:utilizacao}
      \end{figure}
      



    %
    %
    %
    \subsubsection{Simulação 03 - Comparação com arquitetura padrão}

     O terceiro cenário de simulação teve como objetivo comparar os tempos de respostas e
a vazão para as operações de registro e estabelecimento de sessão, e a taxa de carga nos
servidores CSCF entre as duas arquiteturas. As tabelas \ref{tbl:res-sim03a} e
\ref{tbl:res-sim03b} apresentam um resumo dos resultados obtidos nas simulações, e os
gráficos das Figuras \ref{graf03:tempos} e \ref{graf03:carga} apresentam as comparações
de tempos de resposta e vazão, e carga dos servidores CSCF respectivamente.

   \begin{table}[h!]
      \centering
      \caption{Resultados da Simulação 03 (Arquitetura Padrão)}
      \label{tbl:res-sim03a}
      \begin{tabular}{|c|c|c|c|c|c|c|}
        \hline $\lambda (req/seg)$ & $U_{I-CSCF}$ & $U_{P-CSCF}$ & $U_{S-CSCF}$ &
$Rr$   & $Rs$  & $V$ \\
        \hline 200  & 45,60\% & 24,30\% & 67,34\% & 0,30s &  0,52s & 374 \\
        \hline 520  & 88,40\% & 87,85\% & 88,93\% & 5,49s &  7,54s & 486 \\
        \hline 676  & 89,50\% & 89,80\% & 90,53\% & 6,94s &  9,32s & 489 \\
        \hline 1142 & 90,70\% & 90,30\% & 91,00\% & 8,67s & 11,34s & 493 \\
        \hline
      \end{tabular}
   \end{table}


   \begin{table}[h!]
      \centering
      \caption{Resultados da Simulação 03 (Espaço de Tuplas)}
      \label{tbl:res-sim03b}
      \begin{tabular}{|c|c|c|c|c|c|c|}
        \hline $\lambda (req/seg)$ & $U_{CSCF_{1}}$ & $U_{CSCF_{2}}$ & $U_{CSCF_{3}}$  &
$Rr$   & $Rs$  & $V (req/seg)$ \\
        \hline 200  & 60,71\% & 17,43\% & 17,00\% & 0,40s &  1,01s & 390  \\
        \hline 520  & 92,42\% & 71,43\% & 68,57\% & 0,46s &  1,16s & 944  \\
        \hline 676  & 94,00\% & 79,86\% & 77,86\% & 2,25s &  5,08s & 1022 \\
        \hline 1142 & 95,29\% & 77,57\% & 77,71\% & 5,50s & 10,45s & 1024 \\
        \hline
      \end{tabular}
   \end{table}

        \begin{figure}[h!]
         \centering
         \includegraphics[scale=0.6]{graficos/graf03-temposResposta.png}
         \caption{Simulação 03 - Comparação entre os tempos de resposta e vazão}
         \label{graf03:tempos}
        \end{figure}

        \begin{figure}[h!]
         \centering
         \includegraphics[scale=0.6]{graficos/graf03-utilizacao.png}
         \caption{Simulação 03 - Comparação ente as taxas de carga nos servidores CSCF}
         \label{graf03:carga}
        \end{figure}

      Na Figura \ref{graf03:tempos} observa-se uma diferença significativa entre a
arquitetura IMS padrão e a arquitetura baseada em espaço de tuplas, sendo que a
arquitetura baseada em espaço de tuplas suporta uma carga maior de requisições. Para ter
uma comparação mais precisa, o cenário de simulação considerou apenas três Servidores IMS
habilitados no modelo CPN da arquitetura baseada em espaço de tuplas, uma vez que na
arquitetura padrão foram modelados três servidores, o P-CSCF, o I-CSCF e o S-CSCF.
Importante lembrar que na arquitetura baseada em espaço de tuplas, não existe distinção
entre P-CSCF, I-CSCF e S-CSCF, todos os Servidores IMS pode se comportar como qualquer um
dos três.

      O gráfico da Figura \ref{graf03:carga} apresenta algumas informações importantes.
Primeiramente, observando o resultado para uma taxa de chegada de 200 req/seg verifica-se
uma alta taxa de utilização no S-CSCF, enquanto o P-CSCF e o I-CSCF estão sendo
subutilizado.

      Esse comportamento também foi identificado em \cite{QPN-IMS}, conforme pode ser
observado na tabela \ref{tbl:luo}. 

   \begin{table}[h!]
      \centering
      \caption{Resultados obtidos em \cite{QPN-IMS}}
      \label{tbl:luo}
      \begin{tabular}{|c|c|c|c|c|c|c|}
        \hline $\lambda (req/seg)$ & $U_{I-CSCF}$ & $U_{P-CSCF}$ & $U_{S-CSCF}$ \\
        \hline 15  &  4,60\% & 31,20\% & 34,10\% \\
        \hline 40  & 13,30\% & 83,40\% & 91,90\% \\
        \hline
      \end{tabular}
   \end{table}

      É possível notar que existe uma alta taxa de utilização no componente S-CSCF e uma
subutilização no I-CSCF. Nesse aspecto, tanto a simulação realizada por \cite{QPN-IMS} com
QPN, quanto a simulação da arquitetura IMS padrão realizada neste trabalho com CPN,
demonstram que o ponto de gargalo da arquitetura IMS padrão é o S-CSCF.

      Para a arquitetura baseada em espaço de tuplas observa-se no gráfico da Figura
\ref{graf03:carga} uma alta taxa de utilização no Servidor IMS 1, enquanto os Servidores
IMS 2 e 3 apresentam taxas de utilização baixas. Esse comportamento é esperado, uma vez
que as requisições no cenário de simulação utilizado chegam somente pelo Servidor IMS 1,
e, neste caso, esse terá prioridade no atendimento.

      Para os demais cenários, aumentando a taxa de chegada de requisições, observa-se
que a rede com arquitetura IMS padrão está totalmente sobrecarregada, enquanto a rede
baseada em espaço de tuplas apresenta uma folga nos Servidores IMS 2 e 3, com o Servidor
IMS 1 priorizando o atendimento das requisições e distribuindo-as igualmente entre todos
os Servidores IMS da rede. 

      Com os resultados comparativos, nota-se que o fato de a arquitetura baseada em
espaço de tuplas considerar que todos os Servidores IMS podem atuar como P-CSCF, I-CSCF ou
S-CSCF traz um ganho significativo de desempenho, pois o processamento é distribuído entre
todos, sem haver subutilização de recurso em determinados servidores enquanto ocorre uma
sobrecarga em outros. 

%
% Considerações
%
\subsection{Considerações}
    
   A simulação da arquitetura baseada em espaço de tuplas demonstrou que existe
ganhos significativos de desempenho e escalabilidade em relação à arquitetura
padrão. Isso ocorre em função do desacoplamento entre processos oferecido pelo modelo de
programação baseado em espaço de tuplas, e pelo fato de os Servidores IMS hospedarem
todos os elementos responsáveis pelo controle de sessão, o que possibilita um melhor
aproveitamento dos recursos computacionais.
    
   Um dos principais comportamentos observados é a habilidade do componente
\textit{Events Processor} realizar o balanceamento de carga de requisições, sem a
adição de software específico para essa finalidade. Esse comportamento demonstra a
eficácia da proposta de manter um espaço de tuplas distribuído, possibilitando a inclusão
de novos Servidores IMS na rede sem que o \textit{Events Processor} tome conhecimento.

   Com a comparação entre as duas arquiteturas, observa-se que até uma taxa de carga de
200 req/seg (720.000 por/hora) a arquitetura padrão oferece melhores resultados; o tempo
médio de resposta é de 400ms para a arquitetura padrão, enquanto para a arquitetura
baseada em espaço de tuplas o tempo médio é de 650ms. Essa diferença ocorre em função do
\textit{overhead} de comunicação com o espaço de tupla e da rede P2P. No entanto, a
arquitetura baseada em espaço de tuplas escala melhor, e apresenta melhores resultados em
cenários com alta taxa de chegada de requisições, alcançando os objetivos definidos
inicialmente que considera utilização em cenários de larga escala.

